Pushed as draft for pre-review ... The real commit is in 12412c2

This really needs a stable baseline due to the fact that it moves files around, it can be difficult to auto-merge.

Corrected: some debug/saved files I forgot to remove were still in the original push. Cleaned up now.

For review/summary - the directory structure of the modules dir now looks like this:

modules/
├── cfe_app_intf
│   ├── eds
│   ├── fsw
│   │   └── inc
│   └── ut-stubs
│       └── src
├── cfe_assert
│   ├── inc
│   └── src
├── cfe_internal_intf
│   ├── eds
│   ├── fsw
│   │   └── inc
│   └── ut-stubs
│       ├── inc
│       └── src
├── cfe_testcase
│   └── src
├── cfe_testrunner
│   ├── inc
│   └── src
├── es
│   ├── eds
│   ├── fsw
│   │   ├── inc
│   │   └── src
│   └── ut-coverage
├── evs
│   ├── eds
│   ├── fsw
│   │   ├── inc
│   │   └── src
│   └── ut-coverage
├── fs
│   ├── fsw
│   │   └── src
│   └── ut-coverage
├── msg
│   ├── fsw
│   │   ├── inc
│   │   └── src
│   ├── option_inc
│   └── ut-coverage
├── resourceid
│   ├── fsw
│   │   └── src
│   ├── option_inc
│   └── ut-coverage
├── sb
│   ├── eds
│   ├── fsw
│   │   ├── inc
│   │   └── src
│   └── ut-coverage
├── sbr
│   ├── fsw
│   │   └── src
│   └── ut-coverage
├── tbl
│   ├── eds
│   ├── fsw
│   │   ├── inc
│   │   └── src
│   └── ut-coverage
└── time
    ├── eds
    ├── fsw
    │   ├── inc
    │   └── src
    └── ut-coverage

CCB:2021-03-03

• This is a draft so needs some more cleanup
• Bumps cmake minimum version to 3.5
• Looking for suggestions on naming option_inc
• Does this fix the missing c99 standard flag in tbl compilation?
• Remove get_current_cflags hack
• Instead of listing cfe-core we now list all the cfe components
• splits up api definitions and types from module headers think about renaming *_extern_api_typedefs.h to avoid confusion with *_api_typedefs.h
  • the extern typedefs could come from an external database
• stubs need to be defined with the library
• Move "semiprivate" functions into a separate header.
  • Which functions should apps be allowed to call? Do we care that apps can't see these functions?
  • Didn't SB use "priv" in the file name for APIs that normal applications should not call?
• There was an attempt to clean up internal headers
  • Should we use "internal" or "private"? What's the difference?
• Minimal and transparent effect on apps that are written "the right way"
• email the community to give people a heads up
• Some projects use CCDD which will break after this change
• Also clean up deprecated elements

@skliper @jwilmot what other words can we use for the "fsw" directory? As our userbase and applications grow I think it would be interesting to have that directory be named something that encompasses more "project types". What about something like "rt_sw" for real-time sw?

I know this is a big paradigm change and we should honor our fsw roots though. Thoughts?

@jphickey would it make sense for cfe_app_intf to instead be named cfe_api ?

@skliper @jwilmot what other words can we use for the "fsw" directory? As our userbase and applications grow I think it would be interesting to have that directory be named something that encompasses more "project types". What about something like "rt_sw" for real-time sw?

I know this is a big paradigm change and we should honor our fsw roots though. Thoughts?

The key for me is that it's uniquely identified vs test or any other code in the repo so from that context "fsw" is sufficient, and doesn't limit use. It is the core Flight Executive and core Flight System, rebranding may be a hard sell. It's not really "real-time" in the classic sense since that depends on OS, and anything I can think of generic enough to cover all uses looses it's meaning.

I still like "fsw" - it has heritage/history, and its obvious what it refers to (i.e. its one of those acronyms that really doesn't need a definition). Given the number of times the word "flight" is referred to in both code and docs (and the overall system name!), this will probably never change.

@jphickey would it make sense for cfe_app_intf to instead be named cfe_api ?

I'm fine with that. What about cfe_internal_intf -- should this be simpler, like e.g. cfe_core maybe? (I originally hesitated from calling it cfe core because this used to refer to the public intf, not the internal one).

@jphickey would it make sense for cfe_app_intf to instead be named cfe_api ?

I'm fine with that. What about cfe_internal_intf -- should this be simpler, like e.g. cfe_core maybe? (I originally hesitated from calling it cfe core because this used to refer to the public intf, not the internal one).

Yeah I was thinking about "internal" but couldn't come up with anything. Maybe private? cfe_core is an easy to overload term so I don't like it

Yeah I was thinking about "internal" but couldn't come up with anything. Maybe private? cfe_core is an easy to overload term so I don't like it

This is a tough one because "private" (at least to me) implies localized to a single module, which this is not (i.e. not shared at all). I sometimes refer to this as "quasi-private" - but I wanted a term that conveys it is shared within the group, but not widely shared beyond the group.

This is a tough one because "private" (at least to me) implies localized to a single module, which this is not (i.e. not shared at all). I sometimes refer to this as "quasi-private" - but I wanted a term that conveys it is shared within the group, but not widely shared beyond the group.

What if we use private then use "local" for the module-specific stuff?

This is a tough one because "private" (at least to me) implies localized to a single module, which this is not (i.e. not shared at all). I sometimes refer to this as "quasi-private" - but I wanted a term that conveys it is shared within the group, but not widely shared beyond the group.

What if we use private then use "local" for the module-specific stuff?

cfe_local? or cfe_scope... local_scope, restricted? internal... where's my thesaurus.

cfe_local?

or cfe-core_local or just core_local?.

Also what is our guidance for underscores vs dashes again?

Separate question, do we want to drop the cfe_* prefix or replace it with core on these directory names? It feels redundant since everything will be under the cfe "repo folder"

Separate question, do we want to drop the cfe_* prefix or replace it with core on these directory names? It feels redundant since everything will be under the cfe "repo folder"

I do concur about the redundant-ness of the directory name - HOWEVER - there are other patterns involved here. The directory defines a CMake target of the same name - this is a common pattern in all modules. (i.e. so "es" defines an "es" target, etc). This becomes apparent when linking, where one has to list the interface in "target_link_libraries" - in this context the "cfe_" prefix makes sense. That is, one does target_link_libraries(${my_app} cfe_api). I suppose a target named core_api would be OK too though.

Build checks passing, should be basically ready for its final review and merge.

Notes from CCB Splinter 2021-03-10

• Open new issue to update file diagrams in documentation
• For Section 4.2.1, Does it make sense to put tables in fsw for apps?
  • The idea is that users will customize what is in that directory
• How are PerfIDs scoped? Are they globally unique or just processor specific?
  • Should we increase the number space ?
• Can we put the CI changes into their own commit?
• Add ci_lab and psp related PRs to "additional context" and add "dependency" label